ATE architecture and method for DFT oriented testing

ABSTRACT

An ATE system is described for testing one or more DFT testing blocks contained in one or more DUTs when coupled to the ATE system. The ATE system includes hardware resources and software processes under the control of a DPK (Distributed Processing Kernel). The DPK couples the hardware resources and software processes as needed for a first DFT testing block to be enabled for testing only when such resources and processes are available and locked for the first DFT testing block. The DPK is coupled to the first DFT testing blocks via data channels and control channels that are selected as needed for having the first DFT testing block enabled for testing. The channels are under the control of an DUTs-ATE interface which is directed by the DPK for connecting the first DFT testing block to the locked hardware resource and the locked software processes. Each set up process corresponding to any subsequent DFT testing block requesting any hardware resource and any software processes that are already locked for use is paused until such locked resource and locked software processes are unlocked and assigned for having that subsequent DFT testing block enabled for testing.

BACKGROUND OF THE INVENTION

The present invention relates to testing of Integrated Circuits (ICs)and semiconductor devices by Automated Test Equipment (ATE).

During typical semiconductor manufacturing processes, ICs are tested toassure proper operation. The ATEs perform the necessary tests to ensurethe quality, with ICs being the Device Under Test (DUT). Complex ICsthese days are typically tested with the help of on-chip DFT (Designedfor Test) including BIST (Built In Self Test) as well as some Built offSelf Test structures (all hereinafter known as DFT structures) inconjunction with readily available ATE. Those DFT structures includevarious testing blocks for performing prescribed test processes. Deviceswith DFT structures can be classified into three categories:

1. Fully autonomous where the DUT just needs one or more power suppliesand one or more clocks to have the testing enabled and subsequent datacaptured without further attention of the tester (operator) and/or theATE.

2. Semi-autonomous where the DUT may need initial set up to start thetest and may need subsequent attention of the tester (operator) and/orthe ATE to receive the testing results. There may also be otherintermediate actions arising from prescribed activity and requiringattention before testing is fully completed.

3. Non-autonomous, where the DUT needs constant attention of the tester(operator) and/or the ATE at regular intervals in order for the testingto be enabled, completed and the generated data captured.

In the currently known ATE architectures used in the test andmeasurement industry, test channels and needed ATE hardware and softwareare dedicated to the testing block under test for the entire testsession of the block test via device pins. The resource allocation isdefined before the test program is executed. The ATE software isdesigned to allow this kind of allocation of the test channels to theblock via the device pins. As will be explained subsequently, this kindof ATE architecture leads to inefficient testing of DFT-oriented devicesin terms: of lower ATE resource utilization, need for higher number ofATE resources, limiting efficient data collection, and inability to testcertain types of devices concurrently with other devices.

The ever increasing pressure to reduce test cost demands reduction inthe cost associated with ATE, which makes a significant portion of theoverall test cost. The conventional ATE architectures are functionallycapable of performing the necessary tests, however, their efficiency fortesting DFT oriented devices is low as mentioned above. As will beexplained, there are disadvantages for having the ATE resourcesconstantly tied to the testing block under test until the testing blockfinishes its tests. The ATE resources include ATE hardware, ATEchannels, ATE software for monitoring and/or controlling channelactivity and for having prescribed test processes conducted and allother associated equipment and circuitry for having testing blocksoperated for testing. In conventional ATE systems, the ATE resources areset up to have access via ATE data and ATE control channels to the ATEhardware and ATE software resources needed for monitoring and conductingall the testing activities for each testing block in the DUT, during theentire test session for that block.

FIG. 1 depicts a conventional test flow diagram 10 of activity blocksand steps for a conventional ATE system well known in the prior art forhaving a DUT enabled for testing. In conventional ATE systems, all ofthe testing blocks are prescheduled for testing. Briefly described, theATE system begins at a Block 11 (marked with START) and moves to a Block12 where set up is arranged (automatically, by an operator or acombination of both) for a first selected testing block. The ATEresources needed for that first selected testing block are assigned. TheATE system then moves to a Block 13 where the entire set up for havingthe selected testing block enabled for testing is arranged using theassigned ATE resources. The ATE system then moves to a Block 14 wherethe actual test is conducted for the testing block. The test results aresubsequently collected (i.e., captured) as part of the activities in aBlock 15. In some cases, e.g., scan test, the results collection canhappen simultaneously with the stimulus application. Subsequently, theATE system moves to a decision Block 16, where a check is made todetermine if another prescheduled testing block is to be enabled fortesting. If there is another prescheduled testing block, the ATE systemmoves along a path 20 (marked with a Y meaning Yes) to a Block 17 wherethat next scheduled testing block is selected. The ATE system then movesto the Block 12 and continues through the subsequent blocks as was donefor the first selected testing block. This process is reiterated untilall the testing activity for all the testing blocks have been completedwhich results in the ATE system moving along a path 21 (marked N meaningNo) from the decision Block 16 to a Block 18 (marked DONE) where the ATEsystem stops its testing activities. In the conventional ATEs, thesequence in which the blocks are selected for testing with a set ofassociated resources is decided before the test execution begins.

FIG. 2 shows a block diagram of an exemplary and more detailed ATEsystem 30 known in the prior art and a graph 31 that depicts thecorresponding test time impact. For ease of understanding and not forlimitation, the ATE system 30 for this description is described withspecifically limited features. The ATE system 30 is coupled to a DUT 32which has four testing Blocks 33 a-33 d each having autonomous DFTstructures that allow parallel testing of these blocks with each testingblock running independently after set up. The DUT 32 can be a single ICdie being tested or one die on a wafer containing many dice eachcontaining DFT structures. For this description all the test Blocks 33a-33 d require the same ATE hardware resources 34 a-34 d and applicablesoftware resources 35 so that the ATE system 30 operates in accordancewith the test flow diagram 10 shown in FIG. 1 for having each of thetest Blocks 33 a-33 d enabled for testing.

If the testing is done one testing block at a time using conventionalarchitectures, the total test time is:

Total test time=s1+t1+r1+s2+t2+r2+s3+t3+r3+s4+t4+r4

Where each # references the corresponding numbered testing block, thetest set up time is s# for that testing block, the test time is t# forthat testing block, and the time to read results is r# for that testingblock.

In contrast, if each testing block was allowed to run in parallel afterset up the total test times can be reduced to:

Total test time=s1+s2+s3+s4+max(t1,t2,t3,t4)+r1+r2+r3+r4

In this case setup and results collection are still sequential due toshared access to the block from the pins. However, after the setup theautonomous blocks can run the tests in parallel.

The parallel concept also applies to the multi-site case where, forexample, each die (having one or more testing blocks) on a semiconductorwafer may not need the attention of the ATE system 30 all the time.However, for the conventional ATE architectures, the multi-site casestill needs replication of ATE hardware and software resources (whichincreases the overall cost) even if the attention of the ATE system 30is needed only a fraction of the total test time. Whereas in the presentinvention this is not the case, so long as the infrastructure exits toconnect ATE resources dynamically to different blocks and/or dice duringthe test flow.

It is known in the prior art to make an infrastructure for connectingATE hardware and software resources dynamically to multiple dies atdifferent instances of time via associated data and control channels. Soit is generally desirable to test a number of dice in parallel. Testingtechniques have been proposed that enable parallel testing of multipledice of a wafer with a single probe. Examples of such parallel schemesinclude those described in U.S. Pat. No. 6,426,904, entitled “Structuresfor Wafer Level Test and Burn-In” to Barth, et al, U.S. Pat. No.6,275,051, entitled “Segmented Architecture for Wafer Test and Burn-In”to Bachelder, et al, U.S. Pat. No. 6,134,685, entitled “Package ParallelTest Method and Apparatus” to Spano, and U.S. Pat. No. 5,896,040,entitled “Configurable Probe Pads to Facilitate Parallel Testing ofIntegrated Circuit Devices” to Brannigan, et al.

However, in the above disclosures, the DUTs must be analyzed todetermine a priori to identify which blocks may be tested in parallelsince there may be blocks that are not suitable for parallel testing dueto either device or ATE constraints. For example, even though thedigital test blocks can be tested in parallel, if there are analog testblocks (such as for testing for radio frequency mutual interference),then those test blocks must be tested serially if analog resources arescarce. In addition, the conventional ATEs also require the resources toremain allocated to the block under test for the entire duration of thetest of that block. As a result, the conventional architectures do notexploit the autonomous nature of DFT blocks to leverage the fullpotential of parallel testing.

SUMMARY OF THE INVENTION

The present invention overcomes the problems described in the priorsection. In accordance with the teachings of the present invention, anATE system is made such that ATE resources are allocated to the testingblock under test (i.e., in the DUT) only when the testing block needsATE attention and allows the channels to cater to needs of other blocksotherwise. In the present invention the ATE resources are available in acommon pool and assigned to devices under test when needed. Thisarrangement allows distributed processing of the test flows.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a test flow diagram for a prior art ATE system.

FIG. 2 is a block diagram of a prior art ATE system and a graphdepicting a corresponding time impact.

FIG. 3 depicts a DFT centric test cell architecture made in accordancewith the teachings of the present invention.

FIG. 4 is a generic test flowchart of a preferred embodiment of thepresent invention.

FIG. 5 depicts a flow diagram of a Process used in the embodiment shownin FIG. 4.

FIG. 6 shows a Resource Manager used in the embodiment depicted in FIG.4.

DETAILED DESCRIPTION

FIG. 3 depicts a DFT centric test cell architecture made in accordancethe teachings of the present invention. In a preferred embodiment 60 ofthe present invention, a hardware (H/W) resources Pool 62 includes ofall the ATE hardware (not shown) that are necessary to enable andperform the testing of a plurality of DUTs 64 each containing four (4)DFT blocks (generally depicted as solid rectangles). Each DFT block, byway of example and not limitation, can be a digital block, a memory oran Analog or RF block. Additionally, as will be described in greaterdetail, the hardware resources Pool 62 has other resources for flexibleand dynamic assignment of elements of the H/W resources Pool 62 tovarious ATE channels and for providing support to handle events,interrupts, protocols, etc., in view of any predetermined stimulusand/or expected data. A software (S/W) processes Pool 66 for DFT blocksincludes a dynamic pool of conventionally known software test processes(not shown) created to handle the testing of any DFT block in the DUTs64. Each software process exists for having one or more DFT blocksoperated for testing as appropriate. All the software test processes arearranged, as is known in the prior art for distributed operating systemswithout undue experimentation, to acquire dynamically any of the ATEhardware in the H/W resources Pool 62 as required for having a specificDFT block operated under a predetermined testing process and torelinquish any of them when the need for the resources by the process isover. A distributed Processing Kernel 68 includes prescribed hardwareand software operating as necessary to set up and have DFT blocksoperated for testing, to allocate ATE hardware in the H/W resources Pool62 to software test processes in the S/W processes Pool 66 and to handleevents that arise when the DFT blocks are operated for testing. TheDistributed Processing Kernel 68 routes each of the events from ATEhardware to the DUT and vice-versa as required to process the eventduring the testing of a specific DUT. It also arranges for secure pathsfor various respective software test processes to connect to theapplicable ATE hardware. The Distributed Processing Kernel 68 furthermanages the allocation of ATE hardware and software resources foroptimal test scheduling.

The embodiment 60 further includes conventional Data Channels 70 thatare preferably made secure from being adversely affected by conditionsand events not arising from the actual testing of the DFT blocks. TheData Channels 70 are used for transferring data to and from the DFTblocks via resources in a DUTs-ATE Interface 72. The Interface 72, byway of example and not limitation, can be a probe card or a loadboard(not depicted). A group of Control Channels 74 are the channels used notonly for providing control signals to couple the DUT-ATE Interface 72 tothe DFT blocks in the DUTs 64, but also for routing the events from theDUTs 64 to the Distributing Processing Kernel 68. The communicationbetween the elements of the H/W resources Pool 62 and the S/W processesPool 66 to and from the DFT blocks is via a dedicated data channel or ashared channel as required.

FIG. 4 shows a generic test flow diagram 80 of a preferred embodiment ofthe present invention. For a selected first DUT of the DUTs 64 (in FIG.3) and one of the DFT blocks therein to be enabled for testing, thepresent invention begins at a Block 81 (marked as START) and moves to adecision Block 82 where it is determined if there is a DFT block that isto be operated for testing. If there is a DFT block to be enabled fortesting, the present invention moves along path 83 (marked with a Ymeaning Yes) to a Block 84. In the Block 84, a parallel Process (to bedescribed subsequently) is forked for the testing of that block. In theBlock 84, the DFT Block is also identified as DFT Block(i), where irepresents a specific DFT Block that is associated with the forkedProcess. Accordingly, for the first selected DUT and the first selectedDFT block therein is identified as DFT Block(1). In this description, asshown in FIG. 3, each of the DUTs 64 contains four (4) DFT Blocks andthere is an unspecified total number of DUTs 64 so that i ranges fromone to the total number of DFT Blocks contained in all the DUTs 64.After the Block 84, the present invention moves along a path 85 back tothe decision Block 82 where the next DFT Block to be operated fortesting is identified and a corresponding Process is evoked.

If all the DFT Blocks have been enabled for testing, the presentinvention then moves from the decision Block 82 along a path 86 to adecision Block 87. In the decision Block 87 it is determined if all theDFT Block processes (to be described in more detail subsequently) forcompleting the test processes enabled in that DFT Block have been done.If yes, the present invention moves along a path 88 (marked with a Ymeaning Yes) to a Block 89 (marked DONE) where the present invention hascompleted its task of having all the DFT Blocks enabled for testing. Ifno, the present invention moves along a path 90 (marked N meaning No)and returns to the decision Block 87 where the present inventioncontinues as previously described until all the DFT Block processes havebeen completed.

FIG. 5 depicts a flow diagram of a Process 100 described in connectionwith the Block 84 (in FIG. 4) where the Process is associated with aspecific DFT Block(i). For this description and understanding of theoperation of the present invention, the DFT Block(1) is the first DFTBlock to be enabled for testing. It should be understood that all theactivities and actions to be subsequently described in FIG. 5 is via thearchitecture described with respect to FIG. 3. The Process 100 begins ata Block 101 (marked as START) and moves to a Block 102. In Block 102, arequest is made for the ATE hardware and software test processes in theH/W resources Pool 62 and the S/W processes Pool 66 (both depicted inFIG. 3) that are needed to set up and execute the testing of a block,which in this case is the DFT Block(1). The Process 100 then moves to aBlock 103 where it waits for a Resources Lock to be placed on therequested ATE hardware and software test processes for the DFT Block(1)in accordance with the architecture described in FIG. 3. After theResources Lock is made, the present invention moves to a Block 104 wherethe set up for having DFT Block(1) enabled for testing is arranged.Conventional ATE systems already exist which can perform this set up andno new invention or undue experimentation is required to perform thisset up step. Thereafter, the Process 100 moves to a Block 105 where theresources that were locked for setting up the DFT Block(1) for testingare released while the locked resources needed for testing the DFTBlock(1) remain locked. The Process 100 then moves to a Block 106 wherethe testing of the DFT Block(1) is enabled using the locked resources.

In the Block 106 the Process 100 also waits for a Block Event. It waspreviously described that the DUTs 64 are categorized as fullyautonomous, semi-autonomous or non-autonomous. As a result, the DUT ineach category has specific Block Events that may occur, such as but notlimited to: testing done with success, testing done due to a failure andother activities that require the attention of the operator and/or theATE testing system being coupled to the DFT Blocks. So upon theoccurrence of the Block Event, the Process 100 moves to a decision Block107 where it is determined if the Block Event is the End of DFT Testingof Block(1). If no, the Process 100 moves along a path 108 (marked Nmeaning No) to a Block 109. In Block 109, the Process 100 requests theresources (e.g., the ATE hardware and software test processes) neededfor a Requested Action to handle the Block Event. The Process 100 thenmoves to a Block 110 where it waits for a Resources Lock to be placed onthe requested resources. After the Resources Lock is made, the Process100 moves to a Block 111 where the Requested Action is executed. Aftercompletion of the Requested Action, the Process 100 moves to a Block 112where the locked resources not required for continuing the testing ofthe DFT Block(1) are released and made available for subsequent use.

The Process 100 then moves along a path 113 and returns to the Block 106where it continues the testing of the DFT Block(1) and waits for thenext Block Event. If the End of DFT Testing of the DFT Block(1) hasoccurred, then the Process 100 moves along a path 114 (marked Y meaningYes) to a Block 115 where a request is made for the resources needed forcapturing the Results (i.e., the data generated from having the DFTBlock(1) operated for its testing processes). The Process 100 then movesto a Block 116 where it waits for a Resources Lock to be placed on therequested resources needed for capturing the Results. After theResources Lock is made, the Process 100 moves to a Block 117 where theResults are captured. The Results are sent over the Data Channels 70 (inFIG. 3) and typically arranged to be displayed for viewing by anoperator, sent to a recording device for subsequent review, or someother activity. After capturing the Results, the Process 100 moves to aBlock 118 where all the locked resources are unlocked and made availablefor subsequent use. After the resources are unlocked, the Process 100moves to a Block 120 (marked DONE) where it is stopped and has completedits task in connection with DFT Block(1).

With reference to FIGS. 3-5, it should be understood that after theProcess 100 has moved from the Block 84 in connection with the DFTBlock(1) and has returned to the decision Block 82, there is another DFTBlock(2) as well as subsequent DFT Blocks(i) that need to be enabled fortesting by the present invention. When the present invention moves tothe Block 84 and forks a Process for handling the DFT Block(2), anotherProcess 100 is invoked which proceeds as described for DFT Block(1).Similarly, the present invention will keep cycling through the decisionBlock 82 until a Process 100 is engaged and forked for each of theremaining DFT Block(i). However, for each DFT Block(i) after DFTBlock(1), the required ATE hardware and software test processes in theH/W resources Pool 62 and the S/W processes Pool 66 may not be availablebecause some or all of those resources may be locked for having DFTBlock(1) to be enabled for testing and for capturing Results.

Accordingly, there will be a series of Processes 100 that will bestarted but each will be paused at the Block 103 if the requiredresources are not all available. If the testing processes to be enabledin each DFT Block(i) are not the same as one another or if there aremultiple instances of required resources that are available, then it ispossible that the resources for enabling one or more other DFT Block(i)are available even though the resources for enabling the DFT Block(1)are locked. For each of those other DFT Block(i) the associated Process100 will continue until each arrives at a block where the neededresources are locked and not available.

FIG. 6 depicts a Resource Manager 200 where each of the Processes 100that is paused because it is waiting for a Resources Lock is placed in arespective Queue 200(n), where n is the total number of queues neededfor handling all the DFT Block(i) remaining after the DFT Block(1) isbeing enabled for testing. In the preferred embodiment of the presentinvention, when the needed resources that are being requested inconnection with a specific DFT Block(i) are unlocked, the correspondingProcess 100 will be removed from its respective Queue 200(n) and will becontinued in the Block 103, 110 116 when such unlocked resources arereserved and locked for further activity. If there are several pausedProcess 100 waiting for the same unlocked resources, the ResourcesManager 200 includes a selection routine in a Block 202 coupled to eachQueue 200(n) for determining which of the paused Process 100 is to beremoved from its respective Queue 200(n). In the preferred embodiment ofthe present invention, the selection routine in the Block 202 trackswhen each Queue 200(n) is created if there are several paused Process100 waiting for the same unlocked resources. The paused Process 100 areeach handled in the time order that each respective Queue 200(n) iscreated with respect to one another. Of course, other possible selectionroutines are possible such as but not limited to a selection routinethat places priority based on relative importance of specific DFTBlocks(i) to be enabled for testing before other DFT Blocks(i) are to beenabled.

As should be understood from the above as applied to the case wherethere is a combination of digital and analog test blocks, the presentinvention does not have to test each DFT block sequentially since thetesting of each block depends upon the availability of the resourcesneeded to each such block. Accordingly, the present invention can testvarious DFT blocks in parallel as hardware and software resources becomeavailable. The present invention avoids the problem in the prior artwhere the testing of analog test blocks would be conducted serially duelimitation of resources and the testing of digital test blocks arepaused. This results in maximum utilization of the resources, reducesthe amount of duplicate resources and minimizes the idle time of each ofthe resources as long as the resources exist for conducting any of thetesting of all the DFT blocks to be tested. If an amount of duplicateATE hardware and ATE software test processes are desired, the associatedincrease cost for such arrange can be evaluated in view of the overalltime that could be saved.

In the above described preferred embodiment of the present invention,all the test blocks of a specific DUT 64 are tested before the testingof a second DUT 64 is scheduled and conducted. An alternative secondembodiment of the present invention is not limited to handling the DUTs64 in a sequence. Since resources are provided for testing any of theDFT blocks of all the DUTs 64, the second embodiment of the presentinvention is arranged so that when specific resources are available, itdetermines which of the DFT blocks can be set up for testing even if thenext DFT block to be tested is from another of the DUTs 64 differentfrom the DFT block currently being enabled for testing. In other words,if each of the four DFT blocks on a specific DUT (of FIG. 3) require thesame resources for testing one another and the current DFT block beingenabled for testing is using a resource that would be needed for thetesting any of the remaining DFT blocks on the same DUT, then thissecond embodiment will set up another DFT block of another DUT fortesting enablement if other resources are available and not locked forthe current DFT block being enabled for testing.

Although the present invention has been described in detail withreference to particular embodiments, persons possessing ordinary skillin the art to which this invention pertains will appreciate that variousmodifications and enhancements may be made without departing from thespirit and scope of the claims that follow.

1. An ATE system for testing or one or more DUTs when coupled to the ATEsystem, wherein each DUT includes one or more testing blocks, the ATEsystem comprising: a hardware resource pool including hardware forhaving testing blocks operated for testing; a software resource poolincluding one or more software processes for having testing blocksoperated for testing; a DPK coupled to the hardware resource pool andthe software resource pool for setting up and for having each of thetesting blocks operated under a prescribed test procedure; datachannels; control channels; and a DUT-ATE interface operable forselecting any of the data channels and control channels for use in aprescribed manner and for releasing any the selected data channels andcontrol channels when their use is no longer required; wherein theDUT-ATE interface is so constructed and arranged that any of the testingblocks of any of the DUTs are coupled to the DPK via respective datachannels and control channels when required; and wherein the ATE systemsis so constructed and arranged that: for one testing block during a setup phase, the needed and available software processes and the needed andavailable associated hardware are reserved in the respective softwareresource pool and the hardware resource pool by the DPK using selectedcontrol channels; the DPK further operating via other selected controlchannels for having the reserved software process and the reservedhardware used during an execution phase where the one testing block isoperated for generating test data for transmission through selected datachannels; after the execution phase is completed, the reserved softwareprocesses and the reserved associated hardware are released and madeavailable; for each and any subsequent testing block that is to beoperated, a corresponding set up phase is started where requests areprocessed for the needed and available software processes and the neededand available hardware to be reserved in the respective softwareresource pool and the hardware resource pool by the DPK using selectedcontrol channels; the DPK further operating via other selected controlchannels for having the reserved software process and the reservedhardware used during the execution phase where the subsequent testingblock is operated for generating test data for transmission through thedata channels; each corresponding set up phase only completed when theneeded software process and needed hardware are available and reservedin the respective software resource pool and the hardware resource pool;after each corresponding set up phase is completed, the reservedsoftware process and the reserved associated hardware after completionof the execution phase are released and made available for subsequentuse.
 2. The ATE system of claim 1 wherein each of the testing blocks isa DFT block having structures therein for conducting autonomous testprocesses when coupled to prescribed software processes and prescribedhardware.
 3. The ATE system of claim 1 wherein each of the testingblocks is a DFT block having test structures therein for conductingsemi-autonomous test processes when coupled to prescribed softwareprocesses and prescribed hardware.
 4. The ATE system of claim 1 whereina resources manager is coupled to the data channels and control channelsas required and operates during each set up phase for selecting theavailable and needed software processes, for selecting the available andneeded hardware, for providing a lock on the selected software processesand a lock on the selected hardware so that their use is only for theexecution phase associated with that set up phase, and for unlocking theselected software processes and selected hardware for subsequent usesafter that execution phase is completed.
 5. The ATE system of claim 4wherein the resources manager in the case where the locked softwareprocesses and locked hardware are being used for one or more priorexecution phases resulting from respective prior set up phases for thecorresponding testing blocks and where one or more subsequent set upphases are requesting any of the locked software processes and thelocked hardware for other respective testing blocks, the resourcesmanager operating to place each request for any of the locked softwareprocesses and any of the locked hardware in a queue and each of thecorresponding subsequent set up phases are paused; the resources manageroperating when any of the locked software processes and the lockedhardware are unlocked to lock such processes and hardware so that thepaused set up phase in the waiting queue requesting the now lockedsoftware processes and the now locked hardware will be continued and theexecution phase corresponding to the set up phase being continued willuse the now locked software processes and the now locked hardware. 6.The ATE system of claim 1 wherein the execution phase for a testingblock includes an intermediate event requiring a prescribed activity anda testing done event; the ATE system being responsive to theintermediate event by starting a corresponding set up phase forreserving any of the needed and available software processes and any ofthe needed hardware for conducting the prescribed activity during theexecution phase; and the ATE system being responsive to the testing doneevent for capturing the generated test data.
 7. The ATE system of claim6 wherein the testing blocks are DFT blocks having structures thereinfor conducting autonomous test processes when coupled to prescribedsoftware processes and prescribed hardware.
 8. The ATE system of claim 6wherein the testing blocks are DFT blocks having test structures thereinfor conducting semi-autonomous test processes when coupled to prescribedsoftware processes and prescribed hardware.
 9. A method for testing oneor more DUTs when coupled to an ATE system, wherein each DUT includesone or more testing blocks, the method of operating the ATE systemcomprising: forming a hardware resource pool including hardware neededfor having testing blocks operated for testing; forming a softwareresource pool including one or more software processes needed for havingtesting blocks operated for testing; coupling a DPK to the hardwareresource pool and the software resource pool for setting up and forhaving testing blocks operated under a prescribed test procedure;providing data channels; providing control channels; operating a DUT-ATEinterface for selecting any of the data channels and control channelsfor use in a prescribed manner and for releasing any of the selecteddata channels and control channels when their use is no longer required;constructing and arranging the DUT-ATE interface so that any of thetesting blocks of any of the DUTs may be coupled to the DPK via therespective selected data channels and selected control channels asrequired; operating a set up phase by having the DPK reserve needed andavailable software processes and needed and available hardware from therespective software resource pool and the hardware resource pool usingselected control channels; operating an execution phase by having onetesting block operated for generating test data for transmission throughthe selected data channels; releasing and making available the reservedsoftware processes and the reserved associated hardware when theexecution phase is completed; coupling each and any subsequent testingblock to a corresponding set up phase where the needed and availablesoftware processes and the needed and available hardware are reserved inthe respective software resource pool and the hardware resource pool bythe DPK using selected control channels; operating an execution phaseassociated with each corresponding set up phase using the reservedsoftware processes and the reserved hardware where the subsequenttesting block is operated for generating test data for transmissionthrough the selected data channels; completing each corresponding set upphase only when the needed software processes and the needed hardwareare available and reserved in the respective software resource pool andthe hardware resource pool; and releasing and making available thereserved software processes and the reserved hardware after completingthe execution phase for each corresponding set up phase.
 10. The methodof claim 9 wherein each of the testing blocks is a DFT block having teststructures for conducting autonomous test processes when coupled toprescribed software processes and prescribed hardware.
 11. The method ofclaim 9 wherein each of the testing blocks is a DFT block having teststructures for conducting semi-autonomous test processes when coupled toprescribed software processes and prescribed hardware.
 12. The method ofclaim 9 for operating the ATE system including: operating a resourcesmanager, during each corresponding set up phase of the testing block,for selecting the available and needed software processes, for selectingthe available and needed hardware, for providing a lock on the selectedsoftware processes and a lock on the selected hardware so that their useis only for the execution phase associated with that set up phase, andfor unlocking the selected software processes and selected hardware forsubsequent uses after that execution phase is completed.
 13. The methodof claim 12 for operating the ATE system including: using the lockedsoftware processes and locked hardware in any of the prior executionphases resulting from any of the respectively prior set up phases forthe testing blocks; pausing each and any subsequent set up phase whichis requesting any of the locked software processes and any of the lockedhardware for other respective testing blocks; placing each paused set upphase in a waiting queue; waiting for any of the locked softwareprocesses and locked hardware to be unlocked and then locking theunlocked software processes and unlocked hardware to enable now lockedsoftware processes and a now locked hardware; associating the now lockedsoftware processes and the now locked hardware with the correspondingpaused set up phase in the waiting queue that requested the now lockedsoftware processes and now locked hardware; continuing that paused setup phase for having the now locked software processes and the now lockedhardware used in the execution phase corresponding to that set up phase;continuing the method until all the remaining execution phasescorresponding to the remaining paused set up phases in the waiting queuehave been processed and completed.
 14. The method of claim 9 whichfurther includes: operating the execution phase with an intermediateevent requiring a prescribed activity before a testing done event hasoccurred; responding to the intermediate event by starting acorresponding set up phase for reserving any of the needed and availablesoftware processes and any of the needed and available hardware forconducting the prescribed activity during the execution phase; andresponding to the testing done event for capturing the generated data.15. The method of claim 14 where there are more than one intermediateevents occurring prior to the test done event and the method respondingto each of the intermediate events.
 16. The method of claim 9 whereinthe testing blocks are DFT blocks having structures therein forconducting autonomous test processes when coupled to prescribed softwareprocesses and prescribed hardware.
 17. The method of claim 9 wherein thetesting blocks are DFT blocks having structures therein for conductingsemi-autonomous test processes when coupled to prescribed softwareprocesses and prescribed hardware.